In a data storage system, many of the objects stored may be related to time. Examples of data storage systems include message data storage systems, such as Microsoft Exchange, for example, databases, such as SQL Server, for example, and the like. Events such as meetings, appointments, and tasks, for example, have a very clear time relationship. Even less obvious events, such as movies, baseball games, and the Tour de France, for example, can have time relationships. An object such as a message may have several time relationships (e.g., time sent, time received, time forwarded, time read, etc.). Modeling simple time relationships, such as time sent, for example, may be simple. All that may be needed is to add a property of type “time” to the object.
The problem, however, gets much more complicated when the relationship between the object and time is not 1-to-1 (a single time at which a meeting occurs, or a single time at which a message was received) but rather 1-to-many. Examples of such relationships are “recurring” events, such as a meeting that repeats every week, or a task that must be performed quarterly. It is not beyond the realm of possibility that eventually a message store may even need to track all the different times a message was read (for example, for regulatory reasons).
In the past, the solution has been to model time-based relationships for each object type separately. Such a solution, however, makes the task of providing a unified view of time-related objects (such as a calendar of not only meetings but also other objects) very difficult to implement, support, and extend. For example, it is common for a meeting to repeat every week, except on holidays. If each time-based relationship were modeled separately, then an “exception” would need to be added to each, and added consistently with the same rules (what holidays exist? On what day do they fall? etc.). To resolve these issues, it would be desirable to have a unified scheme to model recurring time relationships regardless of the underlying object (e.g., message, meeting, appointment, etc.).
In known systems, there may be grammar for recurrence, but no grammar for exceptions. An example of an exception might be “the 28th occurrence of this meeting, which usually falls on Monday, should fall on Tuesday.” A typical calendaring program, however, may fail to detect that the Tuesday on which the 28th occurrence of the meeting is to be held is a holiday. Typically, such a system is implemented via an object (e.g., calendar entry) with annotations that describe the recurrence requirements and the exceptions. However, there is typically no way for the end-user to see the exceptions.